Floating point numbers are often used when precision is required in performing computations using very large or very small numbers. In the floating point number system, the exponent of a number is scaled up or down as the decimal point is shifted. For example, the speed of light can be represented as 3.00.times.10.sup.8 m/s or 0.3.times.10.sup.9 m/s or 30.0.times.10.sup.7 m/s. The exponent is scaled up as the decimal point is shifted left, and the exponent is scaled down as the decimal point is shifted right.
Many computers provide the means, either in software or hardware, to process numbers in floating point or "scientific" notation (as contrasted to fixed point). In this format, the computer word (or, often, a group of several words) is divided into bit groups or fields: ##STR1## This format represents the value defined by: (sign) (2.sup.EXPONENT).multidot.(FRACTION). Floating point values may have 8 digits of precision in the mantissa and 2 or 3 digits of precision on the exponent. This is an IEEE standard bit format for normalized floating point representation. In some machines, the "2" in the above representation is replaced by "16," which amounts to a scaling of the exponent. Both the exponent and fraction are signed: the exponent field carries its own sign, and the explicit sign bit (the leftmost bit of the entire floating point representation) belongs to the fraction. For 32-bit floating point representation, the exponent is typically 8 bits, and the fraction, or mantissa, is typically 23 bits.
Negative zero may result from subtraction of very large numbers. Negative zero refers to a very small negative number. The sign bit is negative to represent the sign of the number, but the fraction field is zero. Similarly, a fraction field of zero with a positive sign bit may represent zero or a very small positive number. When a floating point number with a fraction field of zero and either a positive or negative sign is used as the denominator in a divide operation, a divide by zero error, or exception, occurs.
Avoiding a divide by zero error is essential to efficient, rapid operation of a wide variety of computer and computer-related systems. When performing divide operations with a pipelined divider, it is desirable to detect a divide by zero condition before the divider operation has completed and generated an error. Prior approaches have included waiting for the divide operation to complete and then flushing and restarting the pipeline with very complex error handler logic and/or software. Prior approaches have also included performing two compare operations in series, including one compare to check for a positive zero and one compare to check for a negative zero. However, if two separate compare operations are required to check for positive and negative zeroes, there may not be enough time to detect the divide by zero and take corrective action before the divide operation has completed.
One example of a system in which speed is essential in performing large numbers of calculations is a computer graphics system. Generally, floating point numbers are used to represent values for the vertices in three-dimensional space, for example, in x, y, and z coordinates. The computer graphics systems are commonly used for displaying graphical representations of objects on a two-dimensional display screen. Current computer graphics systems can provide highly detailed representations and are used in a variety of applications.
The basic components of a typical computer graphics system include a geometry accelerator, a rasterizer and a frame buffer. The system also may include other hardware such as texture mapping hardware. In typical computer graphics systems, an object to be represented on a display screen is broken down into a plurality of graphics primitives. Primitives, such as points, lines, vectors and polygons (e.g., triangles), are basic components of a graphics picture. Typically, a hardware/software scheme is implemented to render (draw) on a two-dimensional display screen, the graphics primitives that comprise a view of one or more objects. The geometry accelerator receives, from the host computer, vertex coordinate and color data for primitives that constitute an object to be rendered. When the primitive is a triangle, for example, the host computer may define the triangle in terms of the x, y, z coordinates and the red, green, blue (R, G, B) color values of each vertex. The geometry accelerator typically performs transformations on the vertex coordinate data (i.e., to screen space coordinates), decomposes quadrilaterals into triangles, and may perform other functions, such as lighting, clipping and performing plane equation calculations, for each primitive. The output from the geometry accelerator, referred to as rendering data, is used by the rasterizer (and optional texture mapping hardware) to compute final screen space coordinates and R, G, B color values for each pixel constituting the primitives. The pixel data is stored in the frame buffer for display on a display screen. Some graphics systems are pipelined such that various operations (such as transformations, interpolation, etc.) are performed simultaneously by different components on different object primitives.
The operations of the geometry accelerator are highly computation intensive. One frame of a 3-D graphics display may include on the order of hundreds of thousands of primitives. To achieve state of the art performance, the geometry accelerator may be required to perform on the order of hundreds of millions of floating point calculations per second per chip. Furthermore, the volume of data transferred between the host computer and the graphics hardware is very large. The data for a single quadrilateral may be on the order of 64 words of 32 bits each. Additional data transmitted from the host computer to the geometry accelerator includes lighting parameters, clipping parameters and any other parameters needed to generate the graphics display.
Functions of the geometry accelerator may include three-dimensional transformation, lighting, clipping, and perspective divide operations as well as plane equation generation, performed in floating point format. Geometry accelerator functions result in rendering data which is sent to the frame buffer subsystem for rasterization.
Various techniques have been employed to improve the performance of geometry accelerators, including pipelining and multiprocessing. Nonetheless, the need exists for additional improvements in performance. In particular, the need exists for increasing the efficiency of computations by the geometry accelerator.